Subject: Introduction and Queries

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Fri, 3 Sep 93 15:53:27 EDT

I have some answers to questions posed in the appended note.  My
answers are indicated by ====>.

Steve Klein
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Subject: Introduction and Queries
>From: [email-masked] (Paul Brittain)
>Date: Wed, 25 Aug 93 16:46:41 BST
>Message-Id: <[email-masked]>
>X-Mailer: ELM [version 2.3 PL11]
>
>Since joining the DLSw siglets a few weeks ago, I have been wading through the
>mountains of mail generated so far in search of the answers to several areas
>of the RFC that are unclear to me.
>
>If any of these points have been discussed before, please just point me in the
>direction of the appropriate mail messages.  I have tried to check for such
>mail, but there is a limit to the level of concentration I can maintain through
>1 Mb of mail!
>
>First however, a brief introduction.
>
>My name is Paul Brittain.  I work for Data Connection Limited and have been
>looking at the RFC and SIG traffic to date with a view to identifying 'grey
>areas' that are not specified sufficiently tightly and hence may lead to
>interoperation problems with products from different vendors.
>
>All of the issues I have identified so far are in the area of ciruit setup, so
>I have addressed this note to the connection siglet.  If anyone thinks the
>issues should be referred to other siglets, please feel free to do so.
>
>Some or all of these issues may already be addressed by the 6611, hence I would
>be particularly interested in comments on these issues from the IBM people
>monitoring this siglet.
>
>1) MANAGEMENT OF TOPOLOGY INFORMATION
>=====================================
>
>I have three questions about the following passage under section 4.2.2.1
>"DISCONNECTED state" of RFC 1434.
>
>    "It is assumed that each DLS will build a set of topology tables giving
>     the identity of each DLS that can reach a specific MAC address or a
>     specific NETBIOS name."
>
>a) Later on in this section it states that the CANUREACH will be sent to only
>those Data Link Switches known to be able to reach the MAC address.
>
>This would mean that if, say, the local DLS topology table says that MAC
>address X is reachable by DLS A, and, unknown to the local DLS, X is
>disconnected from A and attached to a token ring reachable by DLS B (and not
>A), the local DLS will never be able to establish a circuit with X again, even
>if DLS B is known to it.  If this seems unlikely, consider the case of portable
>machines that are regularly moved between offices (such as the one I'm typing
>this on at the moment!)
>
>Is it the intention that if a DLS does not get an answer to a CANUREACH
>from the remote DLS listed in its topology table, it should retry the
>CANUREACH to entire DLS mesh?
>

====> Yes, a directed CANUREACH that is not responded to should be
====> retried to other DLS partners.
====>
====> The fact that a DLS maintains topology tables implies that
====> the implementer would have some sort of mechanism for aging
====> the topology data and deleting old reachability information.
====> The 6611 implementation provides the user the ability to configure
====> the amount of time that the topology information for a specific
====> MAC address is maintained.

>b) Why are multiple entries supposed to be maintained for each MAC address?
>Why not maintain only an entry for the last DLS known to be able to reach
>the MAC address?
====> One reason for maintaining more that one DLS partner per MAC

====> address would be due to the fact that if connectivity to last DLS
====> known to be able to reach the MAC address is lost, a directed
====> CANUREACH could still be sent to another DLS partner.
====> However, maintaining only an entry for the last DLS known to be
====> able to reach a MAC address sounds like a reasonable thing to
====> do (especially for the storage constrained).  I think the
====> standard we produce from this siglet should allow one or more
====> DLS partners per MAC address in the DLS topology tables.

>
>c) If multiple entries are to be maintained, what rationale should be
>used for knowing when to delete 'old' entries in the topology tables?
>Potentially, these tables might contain entries for ALL known DLSs for a
>particular MAC, which defeats the object of maintaining the topology table
>(since CANUREACH messages would then be sent to everyone anyway).
>
>I recognize that (c) may be an area where vendors will seek to achieve some
>differentiation for their product, but (a) and (b) ought to be addressed in a
>common way for all vendors.

====> I suggest some sort of method of aging entries and deleting them
====> when the get too old.  I agree that this should be up to the
====> implementer.

>
>2) MULTIPLE CIRCUITS FOR THE SAME DATA LINK ID
>==============================================
>
>A question about the following passage from section 4.2.2.2 "RESOLVE_PENDING
>state" of the RFC.
>
>     "The ICANREACH should be returned to all DLSs that had sent a
>      CANUREACH message."
>
>Is this "all DLSs that had sent a CANUREACH for the same Data Link ID"?
>
>If this is so, are multiple circuits for the same Data Link ID to be set up
>(only one of which is ever used)?
>
>Or is one circuit set up, and it's the origin DLS that first gets its REACH_ACK
>back to the target that gets the circuit?

====> Its the latter, the first REACH_ACK sets up the one (and only)
====> circuit.  However, the RFC does not address on how to inform
====> the other DLS partners that it REACH_ACK is being rejected
====> (due to the fact that another DLS partner established the same
====> circuit already).  The 6611 implementation uses an SSP message
====> similar to the HALT_DL message (that does not require an
====> acknowledgement) to bring down the Data Link started when a
====> REACH_ACK is received after a circuit has already been established
====> due to a REACH_ACK from another DLS partner.  This message started
====> being passed between DLS partners after the publication of
====> RFC 1434.  This siglet definitely has to agree on a method for
====> rejecting REACH_ACKs for already established circuits.  I can
====> provide more details on the 6611 implementation if anyone is
====> interested.

>
>Or, in a similar vein to my first query, is it really necessary to return the
>ICANREACH to all the DLSs when we will only be setting up one end-to-end LLC2
>connection?

====> This is a point that could be put up for debate.

>
>3) UNSUCCESSFUL CANUREACH ATTEMPTS
>==================================
>
>When a DLS issues CANUREACH to other known DLSs, it must maintain a control
>block for this circuit establishment attempt, containing, if nothing else,
>the information that it has the CANUREACH outstanding so that retried TEST
>commands are ignored.  Preferably, this control block would also contain the
>RIF so that it can return the TEST response to the originator.
>
>Each time a CANUREACH is issued to known DLSs, a new control block must be
>created.  Even assuming that these control blocks are 'converted' to circuit
>control blocks as circuits are established,  an ever increasing amount of
>memory will be taken up by control blocks for unsuccessful CANUREACH attempts.
>
>A solution to this would be to timeout the CANUREACH control blocks,
>assuming the attempt to have failed after a certain time period (as,
>presumably, there comes a point when we have to allow further TEST commands to
>generate CANUREACH messages).

====> You are correct.  Outstanding CANUREACH attempts must be timed and
====> and forgotten after a timeout period.

>
>Does this break the protocol?  Consider the following.
>
>        -       Origin sends CANUREACH to target.
>        -       After a while, origin times out circuit set up attempt and
>                destroys control block.
>        -       Target sends ICANREACH to target.
>        -       Origin discards ICANREACH (no control block).
>        -       Target never gets a REACH_ACK.

====> This is a problem that could be solved by the HALT message
====> I alluded to earlier (let's call it a HALT_DL_NOACK for now).
====> If a DLS receives an ICANREACH but does not have an outstanding
====> CANUREACH for the target MAC address, it would send a HALT_DL_NOACK
====> to bring down the started data link.

>
>Although the RFC specifies what to do if a REACH_ACK is lost, this is a
>different case as there is no circuit and there will be no further messages.
>The Target would be left with a circuit in CIRCUIT_PENDING state forever.
>
>One way out of this problem would be not to keep any information about
>CANUREACH requests sent out (indeed, is this what is implied by the 6611
>issuing TEST commands instead of responses?).  However this does not fit with
>the requirement already stated in the SIG that TEST retries are not sent out to
>the DLS mesh (hence you have to keep some data in order to filter out such
>retries).
>
>Failure to keep the RIF from a TEST command that lead to a CUR also requires an
>additional state in the FSMs to cover the wait for a response to the TEST
>command issued after an ICANREACH message is received.  During this time, any
>data received from the Target DLS on that circuit has nowhere to go because no
>RIF has been established yet.

====> This sounds like an implementation specific matter.
====> An implementation that keeps the RIF from the TEST command that
====> generates a CANUREACH would avoid having to maintain the state
====> you describe above.  An implementation that does not save the RIF,
====> and sends a TEST command to get it (like the 6611), would have
====> to maintain an internal state to handle SSP messages that come
====> in before the TEST response.  Either way of handling the RIF
====> should be transparent to the Switch-to-Switch Protocol.

>
>4) RETRIES OF NETBIOS MESSAGES
>==============================
>
>It has been stated that TEST commands are retried by the recipient
>of a CANUREACH message as appropriate for the LAN environment beneath.  Further
>TEST commands received by the origin DLS do not cause further CANUREACH
>messages until a timeout period has expired.
>
>Is the same true of Netbios Name Query commands issued as a result of an
>incoming NETBIOS_NQ message? Or does the origin DLS send a NETBIOS_NQ for
>every Netbios Name Query received?
>

====> NETBIOS NAME_QUERYs are handled like TEST commands, the first
====> is sent in a NETBIOS_NQ and subsequent NAME_QUERYs for the same
====> NETBIOS name are held until the outstanding NETBIOS_NQ is
====> answered (or until a timeout period has expired).

>This issue also applies to Add Name Query requests.

====> The same holds true for ADD_NAME_QUERYs.

>
>5)  SIMULTANEOUS CANUREACH MESSAGES
>===================================
>
>If two CANUREACH messages cross between two DLSs, both trying to set up a
>circuit between the same MAC/SAP pair, we either get two circuits set up or
>confusion over who is the originator of the circuit.
>
>I'll explain that in a bit more detail.
>
>-  FRED broadcasts a TEST to BILL, which is picked up by DLSA and sent as a
>   CUR to DLSB (+ other DLSs that we'll ignore).
>
>-  At the same time BILL issues a TEST to FRED which is picked up by DLSB and
>   sent as a CUR to DLSA.
>
>-  On receiving the CUR, DLSB issues a TEST to BILL, gets a response, allocates
>   a circuit ID and issues an ICR to DLSA.
>
>-  Similarly, DLSA allocates a circuit ID and issues an ICR to DLSB.
>
>-  DLSB (say) then receive the ICR for the same data link ID as the one it is
>   expecting a REACH_ACK for.  Does it now allocate another circuit ID giving
>   us two circuits, or match the ICR with the original circuit?  If the latter,
>   who is the origin DLS? (remember that DLSA will be going through the same
>   processing)
>
>I don't think allowing two circuits is sensible because that gives problems if
>DLSA and DLSB both think they are the origin DLS.  Also, when they come to
>set up the LLC2 connection, both DLSA and DLSB could end up (illegally) asking
>LLC2 to set up the same Link Station twice over.
>
>However if we try to merge the two connection attempts we have several
>problems:
>
>-       the RFC specifies no algorithm for deciding which circuit to drop
>-       the state machine does not allow for merging of circuits in this
>        manner.
>
>One possible solution that almost solves this problem is to regard the Origin
>and Target DLS roles as existing on a 'per message' basis rather than fixed per
>circuit.  The Frame Direction field then serves only to identify which set of
>ID fields to look at in the SSP header.  A DLS can then use the receipt of an
>ICR when expecting a REACH_ACK to merge the two circuit IDs (sending a
>REACH_ACK back specifying the circuit ID it specified on its own ICR sent
>previously).  However this does not solve who issues the CONTACT and CONTACTED
>SSP messages.
>
>This all seems to be getting over-complicated for a simple crossover case.
>Have I missed something in the RFC?
>

====> No you haven't.  The RFC does not address this crossover
====> case.  This siglet should come up with a method to resolve
====> a crossover situation.  One method would be for one DLS to
====> defer to be the target side of a circuit during a crossover
====> since it has the lower MAC address on its side or the circuit.
====> I'll get a proposal together and send it in a future note.
====> If anyone else has any ideas on handling this crossover case,
====> please share it.

>Paul Brittain
>Data Connection Limited
>+44 244 313440

---

From: Bernard Brady <[email-masked]>
Date: Wed, 8 Sep 93 11:22:53 EDT

Steve,

>====> acknowledgment) to bring down the Data Link started when a
Steve,

By  responding to all CANREACH's received an issue is created.

Responding with multiple ICANREACH messages means that  multiple TEST
response are sent by  originating DLSw's.  It is then the originating
device which is responsible for choosing the  route to be used which in
most cases is the first response received.   You have stated that
the current 6611 implementation will respond to all REACH_ACKs received
after the first with a special HALT_DL SSP message.  The issue is 
that there is no correlation between the route picked by the
originating device and the associated DLSw circuit.   By only  acting
upon the first CANUREACH received and ignoring all others this issue
goes away.  

Bernie Brady